It is possible for processes on a computer to run in a “virtual machine” (VM) which is a region within a host computer that appears to the processes within it to be a self-sufficient computer, but is in fact a smaller region running as a guest under the control of a “hypervisor” running in another part of the host computer. The hypervisor is responsible for providing physical resources in the real machine that correspond to the apparent resources in the virtual machine. In some cases, a guest virtual machine may run within a host virtual machine that itself runs on a physical computer.
Such an arrangement may be used, for example, for security or resource management, to restrict processes within the virtual machine from interfering with other parts of the host computer, or for practical reasons, for example, where an application needs, and a virtual machine provides, a guest operating system (OS) different from the native operating system of the host machine.
In general, the hypervisor may take various forms, including, without limitation, a “bare metal” hypervisor, a hypervisor embedded or incorporated in an operating system of the host computer, or one or more hypervisors running in application space under the operating system of the host computer. The “bare metal” hypervisor typically includes as much of an operating system as it needs, but does not support application processes except within its virtual machine. Other configurations with an integrated or separate host operating system and hypervisor may, but do not need to, support application processes in the host operating system's space. Even where the host operating system and hypervisor are not fully integrated, the distribution of functionality between them may vary.
The Trusted Computing Group (TCG) proposes using a hardware device in the host computer, the Trusted Platform Module (TPM) chip, that can verify a signature and prevent code that is not trusted, or that has been improperly modified, from being loaded. That supervision can include verifying both the host computer's own code and the operating system and application code that is to be run within a guest virtual machine.
However, that approach does not prevent modification of the code within the virtual machine after it has been loaded, and if a hacker or a malicious or defective program is able to gain privileged status it can modify other code at least up to the level of the operating system of the virtual machine. The TPM will detect when improperly modified code is reloaded, but that may not be until next time the virtual machine is rebooted, which for a continuously operating system may not be for weeks or even longer. If a hacker is sufficiently cautious not to leave permanent modifications, the TPM may have nothing to detect. That may occur if the hacker considers it more important to cover his tracks than to make subsequent intrusions easier: he may assume that if his intrusion is not detected he will be able to re-enter the system in the same way on future occasions. Also, some hackers may not wish to re-visit the same computer, and therefore may have no need to make lasting changes to the code.
In most modern operating systems, memory pages occupied by program code (both operating system and application code) are set to read/execute only. However, a hacker or malicious program with privileged status could of course reset that status to allow the code to be modified.